Many current computer systems manage user access to resources according to an object-centric paradigm. File system objects (e.g., files and directories) each have an associated access control list (ACL) that defines which users or groups of users are authorized to access the object in which ways. For example, one user (or group of users) may have read access to a particular file while another user (or group of users) may have read and write access to the file.
Using an ACL-based access control system works well for resource managers that have well defined persistent objects, such as the NT System Registry. An ACL can be attached to an object and access decisions can be made based on group membership in a user token and the contents of the ACL. In these types of applications there is little need for any business rule logic such as time of day or other runtime variables that may be relevant to the access decision.
Although the existing object-centric paradigm works well for many types of resource management, it can be unnatural and cumbersome for web-based and line of business applications which would be easier to manage using a resource management system that was organized in terms of the business organizational structure of a company. In these types of applications, authorization decisions are often not easily defined in terms of access to well-defined persistent objects, but rather, may require verifying a work flow or verifying access to multiple distinct application operations, such as querying a database or sending an email notification. Furthermore, access decisions may also be based on business logic such as an expense amount submitted in an expense application or verification of workflow completion. Because applications like these that don't have well defined persistent objects, there are not logical objects with which to associate an ACL. To use the ACL model in this type of an application, a security descriptor must be created at runtime, a token for the user retrieved, and a call made to a user verification function. This process is difficult to implement within a scripting environment. In addition to being an unnatural development model for web-based and line of business applications, the high degree of functionality of the ACL model is not needed in many applications. The functionality of the ACL model adds a degree of complexity to application administration that can be avoided if a more appropriate model can be used.